1. Field of the Invention
This invention relates to distributed processing systems and more particularly relates to a system and method for updating firmware in redundant embedded controllers.
2. Description of the Related Art
Data processing systems often utilize distributed processors to perform a variety of operational, management, and control functions. For example, a server class data processing system may include a main server processor and one or more embedded controllers. While the main server processor communicates with and directs the activities of the embedded controllers, the embedded controllers, in turn, communicate with and direct the operation of other subordinate devices such as memory storage devices and the like.
In one such data processing system 10, as illustrated by the block diagram of FIG. 1, a main service processor 12 communicates with a primary embedded controller 14 through the primary embedded controller's input/output interface 15a via a shared communication path 16. In this example, the shared communication path 16 is a common RS 485 bus, but may include any data communication channel known in the art. The main service processor 12 manages the primary embedded controller 14 including configuring the primary embedded controller 14, monitoring the status of the primary embedded controller 14, and updating the primary embedded controller's firmware 18a, as needed, which resides in a memory device 20a. The memory device 20a may include a static random access memory device, a flash memory device, a dynamic memory device, or other similar data storage device. The firmware 18a may include an operating system 22a that includes instruction code that is executed by the processor 24a to manage subordinate devices 26 such as data storage devices and the like.
In order to provide redundancy, a secondary embedded controller 28 communicates with the main service processor 12 through the secondary embedded controller's input/output interface 15b over the shared communication path 16. The secondary embedded controller 28 communicates with the main service processor 12 and manages the subordinate devices 26 in the event that the primary embedded controller 14 fails or becomes unavailable. In this exemplary data processing system 10, either the primary embedded controller 14 or the secondary embedded controller 28 may be active (“the active embedded controller”) at any given moment, but not both. Whichever embedded controller is not currently active assumes a standby status (“the standby controller”).
The primary embedded controller 14 and the secondary embedded controller 28 may communicate with each other over an inter-controller communication path 30. This communication may include the exchange of data and other information. Additionally, each embedded controller may utilize the inter-controller communication path 30 to query the active/standby status of the other embedded controller. While this example illustrates a primary embedded controller 14 and a secondary embedded controller 28, any number of embedded controllers may be attached to the same inter-controller communication path 30.
In this exemplary system, the primary embedded controller 14 assumes a default active status and the secondary embedded controller 28 assumes a default standby status. Should the primary embedded controller 14 fail or become inactive, the secondary embedded controller 28 detects this change of status via the inter-controller communication path 30 and assumes an active role in the management of the subordinate devices 26 and communications with the main service processor. When the primary embedded controller 14 becomes available again, the primary embedded controller 14 notifies the secondary embedded controller 28 via the inter-controller communication path 30 and reasserts control over the subordinate devices and communications with the main service processor 12.
The main service processor 12 communicates with the primary embedded controller 14 by transmitting messages including the primary embedded controller's address. In order to provide true redundancy, the secondary embedded controller 28 includes an address identical to that of the primary embedded controller 14. The input/output interface of the standby embedded controller is deactivated so as to prevent communication with the main service processor 12. In this manner, whichever embedded controller is currently in standby mode is transparent to the main service processor 12.
As indicated above, the main service processor 12 is tasked with updating an active embedded controller's firmware. Some embedded controllers utilize a tertiary memory device 32, such as an electrically-erasable programmable read-only memory (“EEPROM”) to hold an image 34 of a firmware update. Absent such a tertiary memory device 32, updating an active embedded controller becomes problematic. Because the operating system 22a,22b is a component of the firmware 18a,18b and includes instructions that are executed by the processor 24a,24b, the operation of the embedded controller must be suspended while its firmware is updated. As such, an embedded controller experiencing a firmware update may enter standby mode, allowing its redundant embedded controller to assume management of the subordinate devices 26. However, because the main service processor initiates the firmware update, the redundant embedded controller may not communicate with the main service processor 12 during this process.
In order for the standby embedded controller to function identically to the active embedded controller, the standby embedded controller's firmware must also be updated. However, because the standby embedded controller is transparent to the main service processor 12, there is a need to transparently download firmware to both embedded controllers 14, 28.
Traditional approaches to updating firmware on multiple embedded controllers are generally not transparent to the main service processor. For example, U.S. Pat. No. 6,247,168 describes a programmable tool utilized to program multiple computing devices. However, the programmable tool is aware of each computing device to be programmed and, therefore, programming of a redundant device would not be transparent to the programmable tool.
Another design consideration of current data processing systems is the number of memory storage devices required to update an embedded controller's firmware. For example, U.S. Publication 2004/0030877 describes copying an operating system to a computing device's BIOS. The operating system is then copied from the BIOS to the computing device's firmware. However, this approach requires an additional memory storage device, the computing device's BIOS, to facilitate updating the computing device's firmware.
From the foregoing discussion, it should be apparent that a need exists for an apparatus, system, and method for updating firmware on an embedded controller and a redundant embedded controller wherein updating of the firmware of the redundant embedded controller is transparent to the main service processor. Beneficially, such an apparatus, system, and method would perform this task without the need for a separate memory device to hold an update while it is being loaded into an embedded controller's firmware.